CloudFrontを導入してECサイトのレスポンス改善をした話

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きなネクストモード株式会社 の吉井です。

CloudFront をご存知でしょうか。
AWS が提供している CDN サービスです。

静的コンテンツキャッシュのよる体感レスポンスの向上、グローバルに展開された POP (Point Of Presence) によるパフォーマンスと可用性の優位、エッジプログラミングなど多くの利点があるサービスです。
今回は CloudFront を導入して EC サイトのレスポンスを改善した話を書きます。

本エントリは事実をもとにしたフィクションです。
少々大げさな記述があるかもしれませんがご了承ください。

CloudFront 導入前構成

サイト URL の CNAME は NLB が指定されています。
NLB 配下には Multi-AZ な EC2 が2台あり WordPress が稼働しています。
その裏には RDS が存在します。

CloudFront 導入後構成

CloudFront を導入しました。
サイト URL の CNAME は CloudFront が指定されています。
NLB の代わりに ALB を配置しました。
EC2 以降は変わりありません。

CloudFront 導入前の課題

当該サイトには特集記事というコンテンツが存在しました。
特集記事を公開するとサイトがダウンするといった問題がありました。
問題発生時に CloudWatch で EC2 のメトリクスを確認すると CPU 使用率がバーストの限界に近い位置で張り付いています。

また、特集記事公開以外のタイミングでも EC2 がハングアップし再起動を余儀なくされる事象が度々発生していました。

改善策

実際に行った、および、提示した改善策を記述します。

EC2 スケールアップ

EC2 は t2.medium でした。
これを m5.large などのバーストタイプではないインスタンスへの変更を提案しました。
が、コストが倍以上になるということで難色を示されました。

とはいえ、このままではいつサイトダウンが発生するか不安でしたので Unlimited モードへの変更を行いました。
直近の CloudWatch を確認し Unlimited モードで当座は凌げることを確認したうえでの変更です。

Unlimited モードと固定 CPU のコスト分岐点は公式マニュアルに計算式があるので計算してみてください。
Unlimited モードと固定 CPU を使用する場合

CloudFront

Google Chrome のデベロッパーツールでサイトを調べたところ、静的コンテンツが多いということを把握していました。
CloudFront キャッシュの恩恵を受けられると判断しました。

ユーザーの体感レスポンスの向上はもちろんのこと、オリジン (ALB～EC2) へのアクセスが減ることで前述の EC2 CPU 問題緩和を期待しました。

オリジンが WordPress の場合の CloudFront behavior サンプルは以下のドキュメントを参考にしつつ、動かしながら微調整を行いました。
Best Practices for WordPress on AWS

ALB

NLB は ALB へ置き換えました。
EC2 のセキュリティグループで 0.0.0.0/0 Port 443 を公開していましたが、セキュリティ対策/リソース負荷軽減の理由で EC2 直接アクセスは禁止したいと考えました。
そのために ALB を導入しました。

また、ALB も CloudFront 経由以外でのアクセスを禁止しました。
インターネットの接点は CloudFront のみに限定しました。これもセキュリティ対策です。
ALB を CloudFront 経由に限定する方は以下に詳しいです。

ロギング

CloudFront アクセスログ、ALB アクセスログの保管設定を行いました。
サイトダウンの原因が明らかになっていなかったので調査目的でのログ保管です。
これが大きな助けになりました。

CloudFront、ALB をお使いの方はアクセスログを有効にすることをお勧めします。

htaccess

CloudFront & ALB を導入した後、CPU 使用率は落ち着いてきました。
Unlimited を無効にしても大丈夫と思われるレベルまで下がっています。

それでも稀に vCPU あたりのベースラインを超える時間帯が確認できました。
その時間帯のアクセスログを解析したところ、wp-config.php や .git などの本来見せないほうが好ましいファイルへのアクセスがありました。
これはかなり冷や汗をかきました。一旦 ALB リスナーのルールでブロックしコンテンツ管理者に .htaccess の適切な設定をお願いしました。

ALB でこれらを 403 で返すようにしたところ、不正アクセスは減りました。
おそらくですが、攻撃者側も 403 になったことでスキャンリストから当該サイトを外したと思われます。

まとめ

今回行った対策は以下です。
技術的に難しいことはなく、効果は非常に高いと感じています。

• 静的コンテンツを CloudFront でキャッシュしユーザーの体感レスポンスを向上した
• インターネット接続点を CloudFront に集約しセキュリティを高めた
• アクセスログによって原因調査が容易になった

公開サイトを運営されている方は CloudFront 導入を検討してみてはいかがでしょうか。

事例

クラスメソッドでは CloudFront を用いた事例を公開しています。
ぜひご参照ください。

以上、吉井 亮 がお届けしました。